sh/init.sh.Linux.in: remove uucp group from /run/lock #730
Conversation
I am not aware of a reason why the uucp group should have r/w access to /run/lock. Also the current configuration allows the uucp group to delete and replace entries owned by other users/groups from /run/lock which could be dangerous. Ref https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69933
|
looking over the git history, mounting /run was introduced in 64ef51a, already chowning /run/lock to root:uucp since the beginning, and no explanation of why i'll try to dig a bit but if i can't find anything, this seems good to merge |
|
it seems to be because /var/run/lock is (was?) used by uucp directly: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s09.html |
|
It seems that debian tries (or tried) to move to |
|
seems like at least minicom needs this for its support for "UUCP-style lock files on serial devices". https://linux.die.net/man/1/minicom |
|
minicom will automatically use flock when uucp style doesn't work: https://salsa.debian.org/minicom-team/minicom/-/blob/master/src/updown.c#L482 We may need to fix minicom to work when one instance uses uucp-style and another one uses flock. This is already an issue though. |
I am not aware of a reason why the uucp group should have r/w access to /run/lock. Also the current configuration allows the uucp group to delete and replace entries owned by other users/groups from /run/lock which could be dangerous.
Ref https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69933